It’s an reactive extension for Angular and one of the topics we talked about to Chris Noring at iJS 2018 in London. Why should you use NGRX for your Angular projects? And will GraphQL be the successor of REST? Chris Noring (McKinsey) weighs in on these questions.

Hello from International JavaScript Conference 2018 in London. My name is Ann-Cathrin Klose. Today, I’m talking to Chris Noring from McKinsey. He has given a lot of talks on Angular and some on GraphQL at this conference. Let’s just start with the Angular side of things. You gave a talk on ngrx. It seems to be connected to Angular by the name, but what exactly is that?

Noring: Ngrx is a library meant to be used with Angular. The whole point of ngrx is that it’s an implementation of Redux.
So the question is really, why would I need Redux? The reason why you might need Redux is that you might have a state in your application that starts to get complicated. When it gets complicated, you’re going to end up sooner or later in a mess where you don’t know what component or what view changed what. You’re going to end up with a state in your application that you don’t know how it got there.
So, Redux is a way to actually trace that state change. You can actually go back to a previous state in time, which makes for very easy debugging. It’s making your app predictable.

Why use ngrx and not another state management library or tool?

Noring: I think ngrx is probably the most famous one, but there are definitely alternatives out there. At the end of the day, you don’t actually need ngrx. It’s just a way to make things easier for you.
What we’re talking about is having like a global object at the highest level. The only thing you need to figure out is “How do I change that object so it’s being reflected to all my components?” Ngrx is there to be your friend. It’s able to say “Look, I’m going to take care of how that’s done for you. I’m going to make sure that all your components know about this.”
At the end of the day there are definitely competitors, but ngrx is the biggest one. As a developer, you tend to take the safe option.  The safe option being a well-supported library. Ngrx is very big; on GitHub, there are a lot of fixes being made and it has a very active community around it.
As developers, we want to de-risk the development. We don’t want to go with a library that looks better, but only two people care about. For us as developers: We want to bet on the safe horse.

Is ngrx just for state management or are there any other use cases it can help with for Angular applications?

Noring: At the core of things, it’s stage management, but it definitely helps us with other things. There are supporting libraries to it that help us with things called side effects.
Side effects are when things happen that are asynchronous usually – something happens on the side. Your application wants to access a network resource or it wants to do a call off the internet and say “I want this piece of data”. When that happens, it doesn’t really fit with your application flow. For that reason, there is a sub-library called effects, dealing with the side effects.
There are also other supporting libraries to ngrx, such as dev-tools. That one helps us to actually visualize what’s happening in a browser. That way you’re able to see all the state changes that happened to your application and you’re able to go back and forth in time. This is called time-travel-debugging.
There is also something called Entity. Entity helps us to do boring stuff. There is always a lot of code that we need to write to actually make things like adding a new item, add a list of things, or just query what our state is. Entity helps us with all of that. Instead rewriting this from scratch every time we want to do something, Entity is there with nice helper methods.
There is also a scaffolder helper library that’s going to help us create the components that we need. There are just some core concepts to ngrx that we need to help us building. Otherwise, our fingers are just going to get tired, right? I mean there are core concepts such as Reducers for example, or Selectors – all of that are pieces of code that you don’t have to write if you use the Schematics sub-library.
I think there is more I could mention, but I mentioned Effects, I mentioned Entity, I mentioned dev-tools. All in all, they provide you with a very enterprise-like solution.  So all of those concerns that you have that are not strictly stage management, those are handled by the ngrx echo system as well.

Ngrx sounds like a great tool to use for Angular apps, but there is another trend in the tech-scene right now: GraphQL. What kind of problems does GraphQL try to solve and who might need that?

Noring: So, today you have something called REST which means you have an endpoint up and running. When you say to that endpoint, “I want that piece of data to come back to me”, that’s fine.
But what happens when your application grows? Suddenly, you might have 50 or you might have 100 endpoints. Sometimes or actually quite often you need to build a new endpoint for every time you have a new question.
GraphQL helps us with something called “content negotiation“. This means that you as a client can say, “Well I’m not sure what I need, but I’m gonna ask you for it.“ So, what’s happening is that you got two connection points: one in the frontend and one in the backend that say “I want to establish a connection and I want to talk to you about what I want.“ I might want a product list; I might want a single user or whatever. The point is, the client can decide.
With REST, it’s not like that. It’s the backend deciding “I’m going to give you a list and you’re going to like it.” The difference with GraphQL is that you’re able to say “Well, I want this list, but I only want two columns instead of ten.“
So, why is that important? Imagine that you’re on a mobile phone or a desktop: on a mobile, you’re usually on 3G or 4G. It matters how fast your internet is for the responsiveness of your app.
With GraphQL, you can actually decide that you don’t want the full object graph. Let’s say that an object that comes back to you normally has 100 properties. That actually matters in terms of size. If you’re able to say in GraphQL that you want only 2 properties out of 100, that means what I’m getting back is significantly smaller. For that reason, GraphQL really shines when it comes to the mobile aspect of things.
REST usually solves this by having two different endpoints. It says “I want an endpoint when I know the user is on a good wifi and I want a secondary endpoint when I know the user is on a mobile.” You actually have to make these kinds of concerns in saying “I need to build two different things because I have a mobile client and I have the desktop.”
With GraphQL, you just query it together and say “Look, I know I’m on a mobile, so I’ll ask this really small question.“ I would say that that’s one of the core benefits of GraphQL: You’re able to cater to any scenario.

This sounds like it might start a revolution in API design. Will GraphQL kill off REST?

Noring: That’s kind of a loaded question. I would say we‘re on a level where both are needed. It’s very easy to say that something is going to replace something else, but content negotiation is definitely interesting.
I think REST endpoints are going to keep existing for a really long while. What I see more and more is that people use GraphQL where it shines, where you actually need to have that flexibility. In a lot of cases, REST is actually a really good technology. There is no need to throw everything out just because.

Performance is a big issue on basically all web topics. Usually they say for APIs, you do serverside caching to solve performance issues. Can you do that with GraphQL and if you can’t, how does GraphQL approach this topic?

Noring: GraphQL has a take on it where it says “I have a backend and that backend contains a database which might be REST-based“.
So, what GraphQL does is that it’s going to say “I want to integrate with you“. What it does is that it throws out hooks that say “I want products from here and I want users from this Reddit cache” and so on, right? That means you end up with an image where you got multiple different data sources. All of these data sources might actually internally cache the data. So, GraphQL doesn’t actually need to care about the caching; it can be handled from the data source it is actually talking to.
At the end of the day, GraphQL is just an interface that is able to talk to all of these sources. The caching doesn’t really need to be with GraphQL, because you can still handle it on the other side. Basically, GraphQL is just a mediator in the middle that says “I know lot of data sources but you, as the frontend users, you don’t actually need to care. The only thing you need to know about is me.”

Thank you for the interview!

(Questions were written by Niko Köbler)